[ML] Migrate DRA GCS publishing from Release Manager to dra-prep plugin by vincentDeuschle · Pull Request #3161 · elastic/ml-cpp

vincentDeuschle · 2026-08-17T12:20:21Z

What this changes

Replaces the Release Manager Docker step with the elastic/dra-prep-buildkite-plugin
(+unified-release-dra-processing pipeline trigger).

Before: A docker run against docker.elastic.co/infra/release-manager was
responsible for classifying artifacts, generating the DRA manifest, and pushing
to GCS. Vault credentials were required (secret/ci/elastic-ml-cpp/gcs/creds/prelertartifacts).

After:

elastic/dra-prep plugin (this repo) — runs dractl to classify artifacts,
generate the manifest, and upload to a temporary GCS path using Workload
Identity Federation (no Vault credentials needed).
unified-release-dra-processing pipeline (always runs on main in
elastic/unified-release) — picks up the manifest from the temp path, moves
artifacts to the final GCS product path, and handles container push/sign.

Net result: DRA artifacts are available at the same GCS path as before.

Files changed

.buildkite/scripts/stage_artifacts.sh (new) — downloads .zip and .csv files from the create_dra_artifacts step and stages them into artifacts/ for dractl to process.
.buildkite/pipelines/upload_dra_to_gcs.yml.sh (rewritten) — generator now emits a DRA Prep step (plugin) + Trigger DRA processing step instead of the Release Manager Docker step. Version is read from gradle.properties; workflow is derived from BUILD_SNAPSHOT (already set per-pipeline in catalog-info.yaml).
.buildkite/scripts/steps/upload_dra_to_gcs.sh (deleted) — the Release Manager Docker wrapper is no longer needed.

Why

Part of the platform-wide Release Manager deprecation (#project-stack-releases-improvements).

Notes

DRA prep is skipped on feature branches where create_dra_artifacts produces no artifacts — the depends_on chain handles this automatically.
The S3 upload path (upload_dra_to_s3) is unchanged — it serves day-to-day Elasticsearch builds and is separate from DRA.
WIF registration must be requested in #project-stack-releases-improvements before this can be merged and run successfully.
catalog-info.yaml manages pipelines via Terrazzo — no manual Buildkite UI change needed post-merge.

What you own post-merge

stage_artifacts.sh — update if artifact paths or naming changes.
The elastic/dra-prep plugin version pin — bump when a new version is released.

🤖 Generated with Claude Code

Replaces the `docker.elastic.co/infra/release-manager` Docker step with the `elastic/dra-prep-buildkite-plugin` + `unified-release-dra-processing` trigger, as part of the platform-wide Release Manager deprecation. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Copilot

Pull request overview

This PR updates the ml-cpp Buildkite release publishing flow to stop using the Release Manager Docker image for DRA publishing, and instead use the elastic/dra-prep Buildkite plugin plus a trigger into the unified-release-dra-processing pipeline. This removes the need for Vault-based GCS credentials and aligns with the broader Release Manager deprecation effort.

Changes:

Add a new staging script to gather DRA artifacts into artifacts/ for dractl/elastic/dra-prep processing.
Rewrite the upload_dra_to_gcs pipeline generator to run the DRA Prep plugin and then trigger unified-release processing.
Remove the old Release Manager wrapper step script.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
`.buildkite/scripts/steps/upload_dra_to_gcs.sh`	Removes the legacy Release Manager Docker-based GCS publishing wrapper.
`.buildkite/scripts/stage_artifacts.sh`	Adds artifact download + staging into `artifacts/` for the DRA Prep plugin to consume.
`.buildkite/pipelines/upload_dra_to_gcs.yml.sh`	Switches the pipeline generator to run `elastic/dra-prep` and trigger unified-release DRA processing.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

…cts.sh

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

elasticsearchmachine · 2026-08-18T14:10:22Z

Pinging @elastic/ml-core (Team:ML)

elasticsearchmachine · 2026-08-18T14:10:24Z

Pinging @elastic/ml-core (Team:ML)

edsavage

Thanks for doing this @vincentDeuschle , @navyau09 . I'm generally pretty happy with it but I have a few concerns/questions before giving it the thumbs up. They're inline below.

Also (not in the diff, but an easy follow-up): dev-tools/ingest_build_timings.py still maps upload_dra_artifacts_to_gcs. After the step key rename to dra-prep, timing ingest for this step will go dark until that map is updated.

edsavage · 2026-08-19T03:35:12Z

+rm -rf build/distributions artifacts
+mkdir -p build/distributions artifacts
+
+buildkite-agent artifact download 'build/distributions/*.zip' . --step create_dra_artifacts


create_dra.sh still downloads Windows-style artifact paths (build\\distributions\\*.zip) when combining platform zips, and the S3 upload step uses the broader build/distributions/* glob.

This stager only downloads POSIX *.zip / *.csv. If any needed zip is stored under the backslash path in Buildkite's artifact store, DRA prep can miss it while S3 still gets it.

Could you confirm against a real snapshot build artifact listing that the combined zips + dependencies-*.csv from create_dra_artifacts are always under forward-slash paths? If not, using build/distributions/* (same as S3) then copying would be safer.

I checked the code in create_dra.sh and while it does download buildkite artifacts using backslash paths, the script itself is running on linux agents. If I read the code here correctly, it is combining all downloaded artifacts under a POSIX path.

edsavage · 2026-08-19T03:35:12Z

+
+  - label: ":pipeline: Trigger DRA processing"
+    trigger: "unified-release-dra-processing"
+    async: true


The old GCS step ran in-pipeline, so a collect/upload failure failed the snapshot/staging build. This trigger is async: true, so the ml-cpp build can go green while DRA never lands in the final GCS path.

If that's intentional (unified-release owns retries/visibility) it's worth stating in the PR. If we still want the parent build to fail when processing fails, async: false (or an equivalent status check) is closer to the old behaviour.

Hey @edsavage This is intentional. In the DRA-prep model, unified-release-dra-processing owns visibility, retries, and the final GCS move. The ml-cpp build’s responsibility ends once it hands off the manifest.

edsavage · 2026-08-19T03:35:12Z

    agents:
      provider: gcp
+    plugins:
+      - elastic/dra-prep#v0.1.5:


Two related merge-gate questions:

WIF — the PR notes registration in #project-stack-releases-improvements must happen before this can run. Merging without that means the next snapshot/staging DRA publish fails with no Release Manager fallback. Is WIF registered for ml-cpp yet?

Plugin pin — elastic/dra-prep#v0.1.5 looks fine if that's the org-recommended version. A pointer to the migration doc or another repo on the same pin would help us not drift.

Also: this step uses a vanilla GCP agent (no JDK image). Please confirm dra-prep/dractl is fully provided by the plugin on that agent — S3 still uses the JDK17 image, so it's easy to assume tools that aren't there.

WIF is already configured and it should work : https://github.com/elastic/infra/blob/ca83670976b72a26ddfe887834a5f2aae8d9c56d/terraform/providers/gcp/env/release-artifacts/elastic-release.tfvars

Plugin Pin: v0.1.5 is the current version and we will update the version if there is any change on our end to dractl.
we discussed using a floating tag (v0 or @latest) but decided to keep pinning for now as it gives us control over when product pipelines pick up dractl changes. As we will start making a bigger change to support Two-Speed Stack Release project.

dractl is installed by the plugin itself as part of its post-command hook and it does not rely on any tooling from the JDK17 image

edsavage · 2026-08-19T03:35:12Z

+    STACK_VERSION="${STACK_VERSION}-${VERSION_QUALIFIER}"
+fi
+
+if [ "${BUILD_SNAPSHOT:-true}" = "false" ] ; then


Nit / robustness: this treats anything other than the string false as snapshot (and appends -SNAPSHOT). create_dra.sh only appends -SNAPSHOT when BUILD_SNAPSHOT = "true".

Catalog sets "true" / "false", so today's pipelines are fine. An unset/empty/True value would still diverge (prep suffixes, create_dra does not). Safer to copy the create_dra.sh check exactly.

Thanks, I updated the behaviour accordingly.

Align BUILD_SNAPSHOT handling in upload_dra_to_gcs.yml.sh with create_dra.sh: use an explicit empty-check to default to true, then test for = "true" rather than != "false". Rename the upload_dra_artifacts_to_gcs step key in ingest_build_timings.py to dra-prep to match the new pipeline step key. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

vincentDeuschle · 2026-08-19T12:30:08Z

Thanks for doing this @vincentDeuschle , @navyau09 . I'm generally pretty happy with it but I have a few concerns/questions before giving it the thumbs up. They're inline below.

Also (not in the diff, but an easy follow-up): dev-tools/ingest_build_timings.py still maps upload_dra_artifacts_to_gcs. After the step key rename to dra-prep, timing ingest for this step will go dark until that map is updated.

Thanks @edsavage , I updated the PR based on your comments. Please let me know if you have any further concerns. For the rollout, I think it might be useful to test this out on a dev branch first, before we merge that into main. @edsavage @navyau09 would you agree to that?

navyau09 · 2026-08-19T12:38:53Z

Thanks for doing this @vincentDeuschle , @navyau09 . I'm generally pretty happy with it but I have a few concerns/questions before giving it the thumbs up. They're inline below.
Also (not in the diff, but an easy follow-up): dev-tools/ingest_build_timings.py still maps upload_dra_artifacts_to_gcs. After the step key rename to dra-prep, timing ingest for this step will go dark until that map is updated.

Thanks @edsavage , I updated the PR based on your comments. Please let me know if you have any further concerns. For the rollout, I think it might be useful to test this out on a dev branch first, before we merge that into main. @edsavage @navyau09 would you agree to that?

Hey @vincentDeuschle Yes, agreed. Please trigger a test build on the branch

vincentDeuschle · 2026-08-19T14:50:36Z

Thanks for doing this @vincentDeuschle , @navyau09 . I'm generally pretty happy with it but I have a few concerns/questions before giving it the thumbs up. They're inline below.
Also (not in the diff, but an easy follow-up): dev-tools/ingest_build_timings.py still maps upload_dra_artifacts_to_gcs. After the step key rename to dra-prep, timing ingest for this step will go dark until that map is updated.

Thanks @edsavage , I updated the PR based on your comments. Please let me know if you have any further concerns. For the rollout, I think it might be useful to test this out on a dev branch first, before we merge that into main. @edsavage @navyau09 would you agree to that?

Hey @vincentDeuschle Yes, agreed. Please trigger a test build on the branch

I did a test run which succeeded, but I haven't had time yet to verify the uploaded artifacts. I'll follow up here tomorrow. https://buildkite.com/elastic/ml-cpp-snapshot-builds/builds/6950#job-01a01a44-440d-451b-b641-6c8af690e018

edsavage

LGTM

vincentDeuschle · 2026-08-20T07:46:40Z

Thanks for doing this @vincentDeuschle , @navyau09 . I'm generally pretty happy with it but I have a few concerns/questions before giving it the thumbs up. They're inline below.
Also (not in the diff, but an easy follow-up): dev-tools/ingest_build_timings.py still maps upload_dra_artifacts_to_gcs. After the step key rename to dra-prep, timing ingest for this step will go dark until that map is updated.

Thanks @edsavage , I updated the PR based on your comments. Please let me know if you have any further concerns. For the rollout, I think it might be useful to test this out on a dev branch first, before we merge that into main. @edsavage @navyau09 would you agree to that?

Hey @vincentDeuschle Yes, agreed. Please trigger a test build on the branch

I did a test run which succeeded, but I haven't had time yet to verify the uploaded artifacts. I'll follow up here tomorrow. https://buildkite.com/elastic/ml-cpp-snapshot-builds/builds/6950#job-01a01a44-440d-451b-b641-6c8af690e018

I compared the artifacts uploaded to GCS of this test run (build id 9.6.0-190ae695) with the latest scheduled build on main (build id 9.6.0-0bf10cac). The list of file names under both gs://elastic-artifacts-snapshot/ml-cpp/<build_id>/* prefixes is identical.

I will merge this PR and continue to monitor through our scheduled snapshot builds.

elasticsearchmachine added the v9.6.0 label Aug 17, 2026

edsavage requested a lite review from Copilot August 17, 2026 22:19

Copilot started reviewing on behalf of edsavage August 17, 2026 22:20 View session

Copilot AI reviewed Aug 17, 2026

View reviewed changes

Comment thread .buildkite/pipelines/upload_dra_to_gcs.yml.sh

Comment thread .buildkite/scripts/stage_artifacts.sh Outdated

navyau09 and others added 3 commits August 18, 2026 14:21

buildkite: fail loudly if dependencies.csv is missing in stage_artifa…

ceaa860

…cts.sh

Copilot fix

a441df6

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Copilot fix

38c63cd

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

vincentDeuschle marked this pull request as ready for review August 18, 2026 14:02

vincentDeuschle added >enhancement :ml labels Aug 18, 2026

edsavage reviewed Aug 19, 2026

View reviewed changes

edsavage approved these changes Aug 19, 2026

View reviewed changes

vincentDeuschle merged commit 7a29b4b into main Aug 20, 2026
24 checks passed

Uh oh!

Conversation

vincentDeuschle commented Aug 17, 2026

What this changes

Files changed

Why

Notes

What you own post-merge

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

elasticsearchmachine commented Aug 18, 2026

Uh oh!

elasticsearchmachine commented Aug 18, 2026

Uh oh!

edsavage left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

edsavage Aug 19, 2026

Choose a reason for hiding this comment

Uh oh!

vincentDeuschle Aug 19, 2026

Choose a reason for hiding this comment

Uh oh!

edsavage Aug 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

navyau09 Aug 19, 2026

Choose a reason for hiding this comment

Uh oh!

edsavage Aug 19, 2026

Choose a reason for hiding this comment

Uh oh!

navyau09 Aug 19, 2026

Choose a reason for hiding this comment

Uh oh!

edsavage Aug 19, 2026

Choose a reason for hiding this comment

Uh oh!

vincentDeuschle Aug 19, 2026

Choose a reason for hiding this comment

Uh oh!

vincentDeuschle commented Aug 19, 2026

Uh oh!

navyau09 commented Aug 19, 2026

Uh oh!

vincentDeuschle commented Aug 19, 2026

Uh oh!

edsavage left a comment

Choose a reason for hiding this comment

Uh oh!

vincentDeuschle commented Aug 20, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

edsavage left a comment •

edited

Loading

edsavage Aug 19, 2026 •

edited

Loading